publié le 25/07/2021 à 12:00 par Olivier Poncet
Vous louez un serveur dédié chez un hébergeur comme Kimsufi, SoYouStart, Scaleway, etc, mais malheureusement ce dernier ne vous propose pas le template d’installation du système d’exploitation de vos rêves. Et cerise sur le gâteau, il ne vous donne pas non plus accès à un KVM sur IP ou bien l'IPMI de la machine pour pouvoir installer votre système d’exploitation depuis une image ISO.
Dans cet article, je vais vous expliquer comment contourner cette limitation et installer votre système d’exploitation favori en mettant en place un KVM virtuel avec QEMU.
Pour pouvoir installer le système d’exploitation de votre choix, vous allez avoir besoin d’un serveur dédié (voir la section suivante), de la possibilité de démarrer sur un mode live « recovery » ou « rescue », du client OpenSSH ou bien PuTTY si vous êtes sous Windows et que vous n’avez pas installé WSL, et d’être un peu à l’aise avec la ligne de commande.
Pour cet article, je vais utiliser un serveur dédié à bas coût loué chez l’hébergeur Kimsufi, filiale lowcost d’OVH. Mais la procédure est applicable chez quasiment tous les hébergeurs, moyennant quelques petits ajustements notamment sur le démarrage en mode « recovery » ou « rescue ». Pour cela, je ne saurais que trop vous conseiller de vous référer à la documentation ou à la FAQ de votre hébergeur favori.
Notez bien que toutes les manipulations que nous allons effectuer vont irrémédiablement détruire toutes les données présentes sur votre serveur. Pensez donc à bien sauvegarder vos données si vous souhaitez les conserver.
Je ne saurais être tenu pour responsable des problèmes qui pourraient survenir pendant les opérations qui seront décrites. Vous êtes prévenus.
La référence du serveur qui servira à la démonstration est le Kimsufi KS-11, mais vous pouvez utiliser n’importe quel autre serveur dès lors que le microprocesseur dispose du support de la virtualisation (Intel VT-x ou AMD-V) et de suffisamment de mémoire vive (au minimum 2Gio, mais je recommande plutôt 4Gio).
Voici les principales caractéristiques du serveur :
CPU : Intel Xeon W3520 (4c/8t) @ 2,66GHz
RAM : 16Go DDR3 ECC 1333 MHz
HDD : 2 x 2To
NIC : 1 x 100 Mbps, 1 IPv4 + 1 IPv6 (/128)
Prix : 19,99€ HT/mois (soit 23,99€ TTC/mois)
Ce type de machine est parfait pour en faire un serveur multi-usage sous Debian ou FreeBSD par exemple ou en faire un serveur de virtualisation sous l’hyperviseur Proxmox VE. C’est d’ailleurs le principal usage que j’ai avec mes serveurs dédiés chez Kimsufi et SoYouStart; ils sont installés avec Proxmox VE et hébergent de nombreuses machines virtuelles KVM et conteneurs LXC pour assurer différents services, tels que des sites web, des sauvegardes, etc.
Connectez-vous à votre dashboard et sélectionnez le service correspondant à votre serveur.
Vérifiez bien que vous avez sélectionné le bon serveur, ce serait dommage de vous tromper …
Cliquez sur le bouton « Netboot ». Une boîte de dialogue va s’ouvrir pour vous permettre de sélectionner le mode de redémarrage de votre serveur.
Cliquez sur le bouton « Rescue », puis sélectionnez la bonne image de rescue s’il vous en propose plusieurs (ici un seul choix, rescue64-pro), puis cliquez sur « Suivant ».
Vérifiez les informations présentées, puis si tout est correct cliquez sur « Confirmer ».
Vous devriez alors voir apparaître un message de confirmation. Votre serveur est maintenant prêt à redémarrer en mode « rescue ».
Cliquez ensuite sur le bouton « Redémarrer ».
Après avoir une dernière fois vérifié le nom de votre serveur, cliquez sur « Confirmer ». Votre serveur va alors effectuer un redémarrage à froid (hard reboot) …
Patientez un peu puis connectez vous à votre serveur par ssh avec l’utilisateur root, en utilisant soit le mot de passe que vous recevrez par email, soit la clé SSH définie par défaut dans votre compte client.
user@host:~$ ssh root@{nom-ou-adresse-ip-du-serveur}
Une fois la connexion établie, vous êtes en mode « rescue », c’est à dire connecté à un système d’exploitation Linux live (techniquement une Debian chez Kimsufi et SoYouStart), chargé depuis le réseau et fonctionnant intégralement en mémoire vive.
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@rescue:~#
Avant d’installer le serveur à proprement parler, nous allons d’abord passer par une première étape qui va nous permettre de collecter certaines informations qui seront nécessaires pour la suite, et notamment les informations correspondant à la partie réseau.
Mon conseil est de bien noter toutes ces informations quelque part, elles vous seront bien utiles.
Nous allons tout d’abord collecter quelques informations système.
Commençons par récupérer les informations liées au microprocesseur avec lscpu:
root@rescue:~# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 26
Model name: Intel(R) Xeon(R) CPU W3520 @ 2.67GHz
Stepping: 5
CPU MHz: 1629.426
CPU max MHz: 2668.0000
CPU min MHz: 1600.0000
BogoMIPS: 5333.34
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 8192K
NUMA node0 CPU(s): 0-7
La ligne importante est Virtualization qui nous indique que le CPU supporte bien les instructions liées à la virtualisation, nécessaire pour QEMU.
Nous pouvons vérifier aussi si la virtualisation imbriquée est active ou non :
root@rescue:~# cat /sys/module/kvm_intel/parameters/nested
N
Par défaut elle ne l’est pas. Mais sauf besoin très spécifique, cela ne devrait pas être gênant.
Si jamais vous en avez impérativement besoin pour l’installation de votre système d’exploitation, il vous faudra donc l’activer. Par exemple, si le mode rescue est compilé avec le support des modules, il vous suffira de faire ceci (dans le cas Intel VT-x) :
root@rescue:~# modprobe -r kvm_intel
root@rescue:~# modprobe kvm_intel nested=1
Pour les autres cas qui dépassent un peu le cadre de cet article (AMD-V, mode rescue non modulaire, etc …), vous trouverez bien comment faire avec l’aide de votre moteur de recherche favori :-)
Bon, à priori vous savez combien de disques vous avez dans votre machine, puisque cela fait partie de votre offre de location. Mais voyons comment ces disques sont référencés dans la machine avec lsscsi :
root@rescue:~# lsscsi -s
[0:0:0:0] disk ATA HGST HUS724020AL ABY0 /dev/sda 2.00TB
[1:0:0:0] disk ATA HGST HUS724020AL ABY0 /dev/sdb 2.00TB
La machine dispose ici de deux disques de 2Tio et accessibles sur les périphériques /dev/sda et /dev/sdb.
Toutes ces informations sont souvent récupérables dans l’interface d’administration mise à disposition par votre hébergeur. Mais comme nous avons un mode rescue fonctionnel, nous allons récupérer toutes les informations nécessaires directement en ligne de commande.
Commençons par lister les interfaces réseau présentes avec ip link :
root@rescue:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
4: ifb0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 32
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
5: ifb1: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 32
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
7: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
8: teql0: <NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 100
link/void
9: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ipip 0.0.0.0 brd 0.0.0.0
10: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/gre 0.0.0.0 brd 0.0.0.0
11: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
12: erspan0@NONE: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
13: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
14: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/tunnel6 :: brd ::
Nous constatons que la machine dispose de deux interfaces réseau, eth0 et eth1, la première étant connectée (state UP), la seconde ne l’étant pas (state DOWN). Malheureusement ces interfaces ne sont pas nommées avec la convention « Predictable Network Interface Names ».
Nous allons donc récupérer les nouveaux noms prédictibles qui nous servirons dans le cas d’une installation d’une distribution Linux utilisant ce nommage :
root@rescue:~# udevadm info --path=/sys/class/net/eth0 | grep ID_NET_NAME_PATH
E: ID_NET_NAME_PATH=enp1s0
root@rescue:~# udevadm info --path=/sys/class/net/eth1 | grep ID_NET_NAME_PATH
E: ID_NET_NAME_PATH=enp2s0
Nos deux interfaces eth0 et eth1 correspondent donc aux interfaces enp1s0 et enp2s0 dans la nouvelle convention de nommage sur ma machine.
Évidemment, les noms peuvent être très différents sur votre machine, selon le firmware/bios, le bus utilisé, etc … Donc déterminez-les et notez les quelque part.
Il se peut que votre machine dispose de plusieurs interfaces réseau, mais qu’une seule soit utilisable. Ce qui est systématiquement le cas chez Kimsufi et SoYouStart par exemple. Le plus souvent, seule la première interface réseau est connectée aux infrastructures.
Nous allons donc maintenant déterminer la/les connexions active(s), les adresses IPv4 et IPv6 ainsi que les routes réseau avec les commandes ip addr et ip route.
Récupérons l’adresse IPv4:
root@rescue:~# ip -4 addr show eth0
6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
inet 94.23.18.xxx/24 brd 94.23.18.255 scope global eth0
valid_lft forever preferred_lft forever
Récupérons la route IPv4:
root@rescue:~# ip -4 route
default via 94.23.18.254 dev eth0
94.23.18.0/24 dev eth0 proto kernel scope link src 94.23.18.xxx
Récupérons l’adresse IPv6
root@rescue:~# ip -6 addr show eth0
6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2001:41d0:xxxx:xxxx::1/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::230:xxxx:xxxx:xxxx/64 scope link
valid_lft forever preferred_lft forever
Récupérons la route IPv6:
root@rescue:~# ip -6 route
2001:41d0:xxxx:xxxx::1 dev eth0 proto kernel metric 256
2001:41d0:xxxx:xxff:ff:ff:ff:ff dev eth0 metric 1024
2001:41d0:xxxx:xxxx::/56 dev eth0 proto kernel metric 256 expires 2587195sec
fe80::/64 dev eth0 proto kernel metric 256
default via 2001:41d0:xxxx:xxff:ff:ff:ff:ff dev eth0 metric 1
Terminons par récupérer l’adresse du serveur DNS :
root@rescue:~# cat /etc/resolv.conf
nameserver 213.186.33.99
Chez OVH et ses filiales, c’est 213.186.33.99. Pour votre hébergeur, ce sera une autre adresse IP. Après rien ne vous empêche aussi d’utiliser pour votre système les DNS de Google (8.8.8.8 et 8.8.4.4), CloudFlare (1.1.1.1 et 1.0.0.1), etc … C’est vous qui voyez !
En résumé, voici les informations IPv4 et IPv6 de l’interface eth0/enp1s0 :
IPv4 address : 94.23.18.xxx/24
IPv4 gateway : 94.23.18.254
IPv6 address : 2001:41d0:xxxx:xxxx::1/128
IPv6 gateway : 2001:41d0:xxxx:xxff:ff:ff:ff:ff
nameserver : 213.186.33.99
Surtout notez bien toutes ces précieuses informations, elles vous seront utiles par la suite.
Avant d’installer le futur système d’exploitation, nous allons faire un peu de ménage sur le disque. Attention, à partir de maintenant vous êtes au point de non retour, vous êtes prévenus !
Vérifiez avec la commande mount si un ou plusieurs systèmes de fichiers sont montés depuis le ou les disques durs du serveur. Si tel est le cas, démontez les avec la commande umount.
De même, s’il existait un RAID logiciel, il se peut qu’au boot ce RAID ai été référencé par le système rescue. Dans ce cas utilisez la commande mdadm pour arrêter le RAID logiciel et le détruire.
Vérifiez s’il existe des partitions à l’aide de la commande lsblk
root@rescue:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 0 1.8T 0 disk
├─sdb2 8:18 0 512M 0 part
├─sdb3 8:19 0 1.8T 0 part
└─sdb1 8:17 0 1007K 0 part
sda 8:0 0 1.8T 0 disk
├─sda2 8:2 0 512M 0 part
├─sda3 8:3 0 1.8T 0 part
└─sda1 8:1 0 1007K 0 part
Comme nous avons des partitions existantes, nous allons les détruire manu militari à l’aide de la commande wipefs et ce sur chaque disque présent sur la machine :
root@rescue:~# wipefs --all /dev/sda
/dev/sda: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54
/dev/sda: 8 bytes were erased at offset 0x1d1c1115e00 (gpt): 45 46 49 20 50 41 52 54
/dev/sda: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa
/dev/sda: calling ioctl to re-read partition table: Success
root@rescue:~# wipefs --all /dev/sdb
/dev/sdb: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54
/dev/sdb: 8 bytes were erased at offset 0x1d1c1115e00 (gpt): 45 46 49 20 50 41 52 54
/dev/sdb: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa
/dev/sdb: calling ioctl to re-read partition table: Success
Sinon vous avez aussi la méthode dite « à l’ancienne » consistant à utiliser la commande dd pour écrire des zéro au début du disque
root@rescue:~# dd if=/dev/zero of=/dev/sda bs=1M count=100 conv=fsync
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.697992 s, 150 MB/s
root@rescue:~# dd if=/dev/zero of=/dev/sdb bs=1M count=100 conv=fsync
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.707475 s, 148 MB/s
A partir de maintenant, votre machine est nettoyée et vierge de tout système d’exploitation et de données.
Déconnectez vous de votre session ssh en tapant « exit », ou bien redémarrez la machine en tapant « reboot » si vous avez tripatouillé des tas de choses sans trop savoir ce que vous faisiez (oui, ça arrive).
Reconnectez-vous à la machine, mais cette fois-ci en créant un tunnel sur le port 5900 (protocole vnc) de la machine distante vers votre machine locale :
user@host:~$ ssh -L5900:127.0.0.1:5900 root@{nom-ou-adresse-ip-du-serveur}
L’option -L permet donc de créer un tunnel avec le protocole SSH permettant de connecter un port local vers une adresse IP et un port distant.
Cette opération est nécessaire car nous allons utiliser QEMU avec son serveur vnc intégré et comme nous ne souhaitons pas que le port vnc soit ouvert et accessible sur internet, ceci sécurisera donc notre session vnc et donc notre installation.
Il est maintenant grand temps de télécharger notre image ISO d’installation à l’aide de wget ou en téléversant l’image ISO sur votre server avec sftp.
Ici je vais installer Proxmox VE 7 sur ce serveur, je vais donc télécharger l’image depuis download.proxmox.com :
root@rescue:~# wget http://download.proxmox.com/iso/proxmox-ve_7.0-1.iso
--2021-07-25 16:51:21-- http://download.proxmox.com/iso/proxmox-ve_7.0-1.iso
Resolving download.proxmox.com (download.proxmox.com)... 2001:41d0:203:7470::34, 51.91.38.34
Connecting to download.proxmox.com (download.proxmox.com)|2001:41d0:203:7470::34|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1064886272 (1016M) [application/octet-stream]
Saving to: ‘proxmox-ve_7.0-1.iso’
proxmox-ve_7.0-1.iso 100%[===========================================================================================================================================>] 1016M 11.1MB/s in 92s
2021-07-25 16:52:53 (11.1 MB/s) - ‘proxmox-ve_7.0-1.iso’ saved [1064886272/1064886272]
Pour rappel, notre session rescue est une distribution live et tourne intégralement en mémoire vive. L’image ISO est donc bien stockée en mémoire vive. Assurez-vous d’avoir suffisamment de mémoire vive pour stocker l’image ISO de votre média d’installation et pour lancer la machine virtuelle QEMU.
Nous y voici, nous sommes aux porte de l’installation du nouveau système d’exploitation.
Assurez-vous que l’utilitaire QEMU est présent sur votre machine :
root@rescue:~# which qemu-system-x86_64
/usr/bin/qemu-system-x86_64
S’il QEMU n’est pas disponible, installez-le avec apt (si votre rescue est de type Debian) ou bien récupérez un binaire statique et déposez-le dans le répertoire /usr/bin.
Nous allons créer une machine virtuel avec QEMU qui utilisera les disques physiques du serveur (ici deux disques) et l’image ISO comme support d’installation. Selon les capacité de votre serveur, à vous d’ajuster les caractéristiques de la machine virtuelle en nombre de cœurs et en mémoire vive. Mais sachez que dans l’immense majorité des cas, ce n’est pas très structurant pour un processus d’installation Linux, FreeBSD ou OpenBSD. Quant à Windows … Débrouillez-vous !
Dans l’exemple ci-dessous, la machine virtuelle va exposer un cpu virtuel identique au serveur, avec 4 cœurs, 4Gio de mémoire vive, une interface réseau virtuelle, les deux disques physiques du serveur, un lecteur optique avec l’image ISO. De plus, nous allons créer un serveur vnc pour pouvoir accéder à la machine virtuelle qui écoutera sur le port 5900 et uniquement sur l’interface de loopback.
root@rescue:~# qemu-system-x86_64 -enable-kvm -vnc 127.0.0.1:0 -cpu host -smp 4 -net nic -net user -m 4096M -hda /dev/sda -hdb /dev/sdb -cdrom proxmox-ve_7.0-1.iso
Description des options :
-enable-kvm : utilise le support de kvm, la couche de virtualisation de Linux
-vnc 127.0.0.1:0 : créé un serveur vnc sur l'interface de loopback, port 5900
-cpu host : expose un cpu virtuel identique au cpu hôte
-smp 4 : expose quatre coeurs
-net nic : créé une interface rféseau virtuelle
-net user : crée un réseau virtuel NAT avec DHCP
-m 4096M : expose 4Gio de mémoire vive
-hda /dev/sda : utilise le disque physique /dev/sda comme 1er disque de la VM
-hdb /dev/sdb : utilise le disque physique /dev/sdb comme 2nd disque de la VM
-cdrom proxmox-ve_7.0-1.iso : expose l'image ISO d'installation dans un lecteur optique virtuel
Depuis votre machine locale, c’est à dire votre PC ou votre Mac, utilisez un client vnc pour vous connecter à la machine virtuelle et dérouler le processus d’installation. Il suffit d’utiliser votre client vnc et de le faire pointer sur le port 5900 de votre machine locale (localhost ou 127.0.0.1), puisque je le rappelle nous avons créé un tunnel SSH entre la machine locale et le serveur sur le port 5900.
Pour l’exemple, je vais utiliser remote-viewer, mais n’importe quel client vnc fera l’affaire.
user@host:~$ remote-viewer vnc://localhost:5900
A ce moment là, vous devriez avoir accès à l’installeur qui tourne dans votre machine virtuelle sur votre serveur.
Si tel est le cas, bravo ! Vous venez de créer une sorte de KVM virtuel qui va vous permettre d’installer le système d’exploitation de votre choix sur votre serveur :-)
Au démarrage de la machine virtuelle, nous sommes accueillis par le chargeur de démarrage
Après avoir sélectionné l’option d’installation, nous passons au démarrage de l’installeur
Comme le support de la virtualisation imbriquée n’est pas disponible, un message nous en informe, mais ce n’est pas requis pour l’installation de Proxmox
Nous prenons maintenant connaissance de la licence utilisateur, puis nous l’acceptons
Pour le partitionnement, nous allons créér un RAID-1 en ZFS sur les deux disques physiques disponibles
Ensuite nous configurons la locale ainsi que la timezone
Puis vient la saisie du mot de passe et de l’adresse email de l’administrateur système
Pour les paramètres réseau, nous renseignons le nom du serveur et l’adresse IP du DNS, le reste nous n’y touchons pas pour le moment
Nous sommes maintenant prêts à installer … Ready ? Set … Go !
Installation en cours …
Installation terminée !
Redémarrage de la machine virtuelle
Chargeur de démarrage du système d’exploitation …
Système d’exploitation démarré !
Une fois le système d’exploitation installé et démarré, logguez-vous avec l’utilisateur root afin d’ajuster les paramètres réseau.
Editez le fichier /etc/hosts et si nécessaire changez l’adresse IP 10.0.2.15 avec l’adresse IP réelle de votre machine.
Editez le fichier /etc/network/interfaces (dans le cas d’une Debian ou dérivée comme Proxmox), changez l’adresse IP 10.0.2.15 avec l’adresse IP réelle de votre machine, changez l’adresse IP 10.0.2.2 par l’adresse IP réelle de la gateway, puis changez le nom d’interface ens3 avec le nom réel de votre interface physique.
Une fois ces ajustements effectués, vous pouvez arrêter la machine virtuelle en tapant la commande shutdown -h now.
Reconnectez-vous sur votre interface de gestion et rétablissez le mode de démarrage sur le disque dur du serveur, en suivant les mêmes étapes que pour passer en mode rescue, mais en sélectionnant Disque dur au lieu de Rescue.
Revenez sur la session ssh de votre serveur, la machine virtuelle QEMU doit normalement être arrêtée. Dans ce cas, vous n’avez plus qu’à tapez la commande reboot pour redémarrer votre serveur.
Si vous avez correctement effectué les différentes étapes et notamment celles de la post-installation, votre serveur devrait être accessible et fonctionner sur votre nouveau système d’exploitation. Si vous n’arrivez pas à pinguer votre serveur ni à vous connecter dessus, alors c’est que vous avez certainement raté quelque-chose.
Cette technique est bien pratique lorsque l’on dispose d’un serveur dédié sans accès direct à un KVM ou l’IPMI. Maintenant vous êtes en capacité à installer l’OS de vos rêves sur votre machine sans être limité aux templates de votre fournisseur.